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ABSTRACT 

As  Air  Mobility  Command’s  (AMC’s)  primary  wing-level  command  and  control 
system,  the  Command  and  Control  Information  Processing  System  (C2IPS)  plays  a 
critical  role  in  the  success  of  AMC  operations  around  the  world.  C2IPS  needs 
improvement  if  it  is  to  fulfill  enough  of  its  user’s  needs  to  truly  improve  AMC’s 
operational  capability.  This  paper  examines  some  of  these  improvements  fi'om  a 
cost/benefit  perspective  in  the  context  of  improving  AMC’s  mission  capability. 

The  paper  examines  four  major  areas  for  improvement  and  makes 
reconunendations  in  each  area.  The  first  concerns  moving  C2IPS  to  a  three-tier 
client/server  architecture  to  improve  response  time  and  reliability.  The  second  area  adds 
to  the  three-tier  concept  by  using  a  “thin  client”  approach  to  reduce  workstation 
hardware  and  software  requirements.  Third,  the  supporting  communications 
infrastructxire  for  both  fixed  node  and  deployed  node  operations  needs  to  better  support 
user  needs  while  maintaining  minimal  costs.  Finally,  several  similar  and  overlapping 
systems  could  be  migrated  in  the  overall  C2IPS  structure  to  minimize  duplication  and 
expense. 

All  four  of  these  areas  offer  opportunities  for  both  performance  and  cost 
improvements  over  the  existing  system,  and  thus  can  improve  AMC’s  overall  mission 
effectiveness. 
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C2IPS:  A  MODEL  FOR  THE  FUTURE 


I.  INTRODUCTION 

The  United  States  Air  Force  (USAF)  Air  Mobility  Command  (AMC)  operates 
hundreds  of  aircraft  daUy  in  operations  that  span  the  globe.  The  command  must  control 
and  follow  these  flights  to  maximize  efficiency  and  effectiveness.  Like  many  major 
airlines,  AMC  uses  an  extensive  collection  of  computers  and  communications  equipment 
to  ensure  proper  conunand  and  control  of  its  flights.  There  are  currently  many  different 
systems  and  subsystems  that  perform  various  required  functions.  The  primary  system 
used  at  the  operational  wing  level  is  called  the  Command  and  Control  Information 
Processing  System,  or  more  conmionly,  C2IPS.  C2IPS  is  primarily  a  wing  system  that 
conununicates  with  higher  level  headquarters.  Unfortunately,  C2IPS  has  been  the  object 
of  considerable  scrutiny  as  many  users  believe  that  it  does  not  suit  their  needs  very  well. 

The  Rand  Corporation  postulates  that  command  and  control  (C2)  systems  have 
eight  operational  objectives.  While  the  Rand  study  concerns  mostly  Army  operations, 
some  of  the  objectives  are  worth  noting  here  to  provide  a  framework  for  evaluating  the 
ability  of  C2IPS  to  perform.  Of  concern  here,  the  study  mentions:  1)  intelligent  displays 
with  decision  support  aids  at  lower  command  levels,  2)  reports  about  the  environment, 
enemy  location,  activities,  and  targets,  and  location  and  status  of  forces  available  to 
commanders  and  their  staffs  at  all  times,  3)  infrastructure  for  C2  in  place  in  the  region 
ahead  of  the  operational  forces  and  operating  as  soon  as  it  is  needed,  4)  the  ability  to 
deploy  forces  rapidly  to  any  region  in  the  world,  unencumbered  by  excessive  equipment 
and  its  operators,  and  finally  5)  the  ability  to  assimilate  forces  in  deployed  commands 
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rapidly  and  continuously  (Cesar,  1995:xiii).  C2IPS  must  fulfill  these  objectives  to 
accomplish  its  intended  task.  In  a  nutshell,  C2IPS  must  provide  timely,  well-displayed 
information,  with  a  minimum  of  infrastructure  in  a  joint,  interoperable  environment. 

Within  the  above  constraints,  a  revised  system  model  for  improving  the 
performance  of  C2IPS  could  eliminate  many  complaints  and  reduce  costs.  Many 
improvements  are  already  in  the  works.  AMC’s  Air  Mobility  Master  Plan  (AMMP)  lists 
many  of  the  system  improvements  as  goals  (AMC,  1996:4-28  through  4-54).  The 
purpose  of  this  study  is  to  evaluate  the  current  improvements  and  propose  some  new 
ones.  By  examining  the  current  marketplace  and  leading-edge  business  practices,  we  can 
gain  valuable  insight  into  the  potential  benefits  of  a  revised  system  model. 

The  two  major  points  of  comparison  will  be  whether  the  revised  system  can 
improve  usability,  and  maintain  or  reduce  costs.  Both  concepts  are  often  difficult  to 
quantify  as  they  directly  affect  each  other.  Sometimes  system  improvements  cost  a  lot 
and  produce  corresponding  productivity  gains.  In  many  cases,  great  sums  of  money 
produce  little  improvement.  In  this  study,  subjective  usability  versus  cost  comparisons 
will  be  the  primary  determinant  of  the  value  of  any  potential  improvements. 

Precise  cost  data  may  not  be  readily  available  in  aU  cases,  but  as  long  as 
productivity  improves  with  little  perceived  cost  impact,  a  change  will  merit 
implementation  or  at  least  further  study.  In  other  instances,  maintaining  existing 
performance  while  reducing  expected  costs  will  prove  advantageous.  Both  methods  of 
improving  C2IPS  effectiveness  possess  merit  and  will  form  the  basis  for  comparison 
between  existing  and  proposed  models. 
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This  study  will  examine  four  key  areas  of  C2IPS.  Simple  flaws  in  the  current 
implementation  will  not  generally  be  addressed  as  many  are  simply  errors  and  glitches 
that  will  continue  to  be  fixed  as  the  system  matures.  The  four  areas  addressed  here  are 
more  structural  and  far  reaching  in  nature.  As  such,  they  could  potentially  produce  large 
gains  in  productivity  per  dollar. 

The  first  area  in  question  is  whether  the  architectural  structure  of  the  entire  system 
is  suitable  for  the  types  of  demands  placed  upon  the  system.  A  discussion  of  the  existing 
structure  and  its  history  will  show  that  while  generally  effective,  the  architecture  may  not 
be  optimal  for  the  type  of  work  performed.  Newer  system  architectures  may  provide 
more  usability,  maintainability  and  reliability  for  lower  cost. 

The  second  area  examines  whether  a  “thin  client”  approach  to  the  end  user 
workstations  could  improve  usability  and  access  to  the  system.  The  thin  client  approach 
is  closely  tied  to  the  aforementioned  system  architecture  but  is  a  separable  issue  that 
concerns  the  amount  of  software  and  data  residing  on  user  workstations.  The  key  issue  in 
this  section  is  whether  the  thin  client  approach  provides  additional  benefits  to  the  user 
and  also  reduces  costs  over  the  current  design. 

Third,  are  C2IPS  communication  systems  adequate  for  worldwide  use?  C2IPS 
currently  relies  heavily  on  dedicated  data  lines.  The  expense  associated  with  this  can  be 
considerable.  Furthermore,  the  current  communications  system  poorly  serves  deployed 
units.  This  in  mind,  what  communications  network  improvements  would  reduce  costs 
and  improve  deployed  connectivity? 
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Finally,  while  C2IPS  is  not  a  panacea  for  wing  level  units,  it  is  perhaps  the  best 
positioned  single  system  for  eliminating  duplication  of  effort.  Dozens  of  smaller  systems 
exist  to  aid  disparate,  yet  highly  interrelated  functional  areas  around  the  wing.  Many  of 
these  smaller  systems  use  similar  or  identical  data  to  that  contained  in  C2IPS.  Users 
frequently  have  to  enter  information  into  several  different  systems.  To  minimize  wasteful 
duplication  of  effort,  C2IPS,  as  the  overarching  command- wide  system,  could  incorporate 
the  functionality  of  lesser  systems.  The  study  will  examine  several  potential  systems  for 
incorporation  and  benefits  of  doing  so  for  each.  Currently  available,  “stovepipe”  systems 
wiU  serve  as  baselines  for  C2IPS  interfaces  and  performance.  The  study  will  examine 
whether  C2IPS  could  effectively  perform  more  functions  and  replace  other  systems. 

Although  these  areas  interrelate,  each  will  be  discussed  separately  with  some 
discussion  of  what  the  current  system  looks  like  and  the  concepts  involved.  Most  of  these 
issues  are  separable,  however  some  may  have  synergistic  effects.  With  this  in  mind, 
however,  each  type  of  potential  improvement  should  be  able  to  stand  alone  in  its  cost 
benefit  analysis.  Each  element  of  any  improved  model  must  be  separately  analyzed,  but 
the  overall  maximum  benefit  may  increase  with  the  combination  of  suitable  interrelated 
elements.  This  study  will  provide  only  cursory  financial  data;  the  point  is  to  raise 
consciousness  of  the  issues  involved  so  that  AMC  can  look  in  the  most  appropriate 
directions  to  improve  the  capability  of  C2IPS.  In  depth  cost  benefit  analysis  will  be 
needed  before  any  actual  changes  are  implemented. 
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II.  SYSTEM  ARCHITECTURE 


The  &st  area  of  study  concerns  whether  the  C2IPS  system  architecture  suits  the 
mission  it  is  required  to  support.  The  current  structure  was  based  upon  the  computer 
technology  available  at  the  time  the  contract  was  originally  conceived  and  has  evolved  a 
little  into  version  2.0C,  which  is  in  the  field  today.  An  initial  examination  of  the  current 
structure  with  some  emphasis  on  the  AMC  organizational  structure  that  the  system  must 
support  will  be  followed  by  some  examples  of  similar  business  structures  and  their 
supporting  C2  systems.  From  this,  some  conclusions  about  the  architectural  structure  of 
C2IPS  should  become  obvious. 

The  current  C2IPS  system  uses  a  distributed  2  echelon  system  architecture.  Every 
C2IPS  served  base  is  called  a  node.  Nodes  may  have  up  to  approximately  75 
workstations,  depending  upon  unit  requirements  (Heitman,  1996).  Almost  all  locally 
needed  data  is  stored  on  each  workstation  or  client  at  each  point  of  use,  while  a  central 
repository  of  data  is  maintained  at  AMC  on  several  mainframe  computers.  The  system 
functions  essentially  by  taking  data  from  the  high  level  servers  or  mainframes,  modifying 
that  data  and  then  returning  any  pertinent  changed  data  back  up  to  the  top  level  for  central 
storage.  There  is  a  file  server  located  at  each  base  that  aids  in  the  transfer  of  data  between 
the  clients  and  the  high-level  servers,  but  it  does  not  function  as  much  more  than  a  relay. 
Most  locally  used  data  resides  on  the  individual  workstations  and  changes  are  replicated 
through  the  file  server  to  the  other  workstations  (Appel,  1996). 

In  the  case  of  C2IPS,  unreliable  data  transmission  media  and  the  mission  critical 
nature  of  the  tasks  performed  resulted  in  the  requirement  to  store  large  amounts  of  data 
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locally.  Each  C2IPS  workstation  maintains  a  large  database  and  is  capable  of  operating 
in  “standalone”  mode  (Shrewsberry,  1996).  In  standalone  mode,  client  data  quickly 
becomes  dated  and  less  valuable.  The  problem  here  is  that  as  a  command  and  control 
system,  C2IPS  should  be  constantly  conununicating.  If  there  is  no  movement  of  the  data, 
there  is  no  need  for  C2IPS.  The  current  C2IPS  system  architecture  emphasizes  client 
independence  over  client  efficiency  and  data  currency.  The  standalone  capability  can 
actually  detract  from  overall  communication  if  its  use  is  prevalent  enough  that  the  data  is 
frequently  outdated. 

The  standalone  capability  also  costs  money.  C2IPS  may  cost  more  than  it  needs 
to  because  each  workstation  stores  a  lot  of  data.  C2IPS  uses  expensive  Digital 
Equipment  Corporation  (DEC)  “Alpha”  workstations  that  have  large  amounts  of  disk 
space  (4  GB)  and  RAM  (96  MB)  to  hold  the  extensive  database  required  to  operate  in 
standalone  mode  (Shrewsberry,  1996).  Every  workstation  needs  to  keep  almost  the  entire 
local  base  database  just  to  function.  The  net  result  of  spending  $20,000  per  workstation 
is  that  fewer  workstations  are  deployed  in  a  fiscally  limited  environment.  For  example,  a 
large  base  like  Travis  AFB,  California  has  about  80  workstations;  it  could  probably  use 
almost  300,  but  cost  limits  deployment  and  thus  overall  system  effectiveness  (Appel, 
1996). 

As  mentioned  earlier,  another  cost  associated  with  large  individual  workstation 
data  inventories  is  obsolescence.  Old  data  is  worse  than  worthless;  incorrect  or  old  data 
can  cause  decision  makers  to  make  poor  decisions.  Furthermore,  large  amounts  of  un¬ 
updated  local  data  will  require  significant  system  effort  to  replace  it.  An  average  C2IPS 
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workstation  can  take  over  30  minutes  to  re-synchronize  its  database  once  it  reconnects  to 
the  network.  Every  individual  workstation  must  stay  synchronized,  so  considerable 
network  load  can  occur  when  many  workstations  simultaneously  resynchronize  data  with 
the  file  server.  It  is  not  uncommon  for  this  to  occur  each  morning  when  everyone  arrives 
for  work  and  turns  on  their  workstations. 

Another  way  to  accomplish  the  same  task  would  be  to  place  all  the  data  on 
centraUzed  global  database  servers.  This  is  basically  the  mainframe  system  model.  This 
system  model  reduces  the  cost  of  the  workstations;  inexpensive  “dumb  terminals”  may  be 
used.  The  expense  in  this  system  model  is  the  requirement  for  reliable,  high  speed  wide 
area  networks  to  connect  the  terminals  to  the  mainframe.  The  mainframe  model  was  used 
extensively  when  computers  were  massive  and  expensive.  Many  examples  of  this  system 
are  still  in  heavy  use  today. 

A  working  AMC  example  of  this  system  is  the  Global  Decision  Support  System 
(GDSS).  Before  C2IPS  was  fielded,  GDSS  was  built  mostly  for  AMC  headquarters  staff 
to  use  for  tracking  AMC  aircraft  around  the  world.  Running  on  DEC  VAX  mainframe 
computers,  GDSS  is  still  the  core  AMC  flight  following  system  and  C2IPS  directly 
interfaces  with  it.  Prior  to  C2IPS  implementation,  however,  AMC  needed  something  for 
its  subordinate  wings  to  communicate  information  up  to  the  headquarters.  The  interim 
solution  was  to  give  GDSS  access  to  the  wings. 

While  GDSS  performed  its  required  function  at  the  wings,  it  was  (and  still  is)  not 
particularly  efficient  for  two  reasons.  First,  the  time  delays  associated  with  passing  each 
keystroke  over  the  wide  area  network  to  the  mainframes  located  at  Scott  AFB,  IL  and 
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Travis  AFB,  CA  were  excessive.  A  keystroke  would  often  take  5  seconds  to  show  on  the 
screen.  Finally,  the  user  interface  possible  on  a  simple  VT-100  type  data  terminal  was 
very  limited.  Users  required  significant  training  and  experience  to  properly  enter  data 
into  each  field.  While  GDSS  serves  the  headquarters  well  as  the  global  data  repository,  it 
is  ill  suited  for  use  in  the  field  as  a  wing  level  command  and  control  system. 

The  undistributed,  central  mainframe  type  of  two-tier  system  model  is 
inappropriate  for  use  in  a  globally  distributed  organization.  It  costs  too  much  to  achieve 
desirable  response  times  for  clients  that  are  located  on  the  other  side  of  the  world. 
Furthermore,  it  is  difficult  to  provide  the  kind  of  user  friendly  interface  desired  for 
reducing  training  costs. 

Essentially,  the  requirement  is  to  support  large,  globally  distributed,  independent, 
and  non-uniform  local  operations  with  a  standardized,  global  corporate  database.  The 
current  architecture  of  choice  for  accomplishing  this  task  in  the  business  world  is  a  three- 
tier  client/server  architecture.  A  middle  layer  of  locally  based  servers  is  added  to  store 
both  local  data,  and  local  policies  or  business  rules.  At  the  same  time,  client  computers 
serve  as  user  friendly  display  and  querying  devices.  The  goal  is  to  communicate  rapidly 
over  reliable  local  area  networks  (LANs)  between  inexpensive  workstations  and 
moderately  powerful  local  servers.  The  middle  tier  of  servers  then  communicates,  if 
necessary,  up  to  the  global  servers  over  wide  area  networks  (WANs). 

One  key  advantage  of  three-tier  over  two-tier  is  that  it  keeps  a  large  portion  of  the 
communications  requirements  at  the  local  level,  where  rehable,  fast  networks  are  less 
expensive  to  build  and  maintain  than  similarly  capable  wide  area  networks.  Local  servers 
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using  high  speed  local  area  network  or  metropohtan  area  network  (MAN)  conneetions 
can  give  nearly  instantaneous  response  for  a  fairly  reasonable  cost.  Three-tier  can  reduce 
network  costs  by  reducing  the  requirement  for  high  capacity,  reliable  long  distance 
connections.  Unlike  in  the  mainframe  two-tier  model  where  every  piece  of  data  must 
pass  over  wide  area  lines,  local  servers  communicate  only  global  data  changes  over 
expensive  wide  area  network  links. 

The  other  key  advantage  to  three-tier  is  that  it  does  not  require  the  computing 
horsepower  at  each  workstation  that  the  distributed  two-tier  model  does.  C2IPS  is  a 
distributed  two-tier  system.  A  three-tier  client/server  architecture  can  provide  the 
response  times  and  user  interface  required  without  requiring  each  workstation  to  have  the 
horsepower  equivalent  to  a  server. 

Basically,  each  base  in  a  three-tier  architecture  would  be  capable  of  operating  in 
“standalone  mode”  to  some  extent,  rather  than  each  individual  workstation.  Since  the 
primary  thrust  of  C21PS  is  that  of  a  wing  level  system,  this  architectural  shift  makes 
sense. 

AMC  AMMP  objective  1.4.1  is  to  “Migrate  AMC  C2  and  transportation  systems 
to  Global  Command  and  Control  System  (GCCS)  Defense  Transportation  Systems  (DTS) 
and  Defense  Information  Infrastructure  (DII)  Common  Operating  Environment  (COE)” 
(AMC,  1996:4-52).  The  COE  is  a  generie  overarching  set  of  standards  that  military 
command  and  control  computer  systems  are  mandated  to  foUow.  It  will  ensure 
interoperability  and  minimize  duplication  of  effort  between  services.  In  the  COE,  the 
three  “tiers”  are  specified  as  data  management,  mission  area  and  support  application,  and 
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user  interface  (Hopkins,  1994:4-1).  The  levels  imply  globally  maintained  corporate  data, 
intermediate  level  data  manipulation  and  storage,  and  low  level  user  interface.  Figure  1 
shows  the  target  AMC  architecture  with  its  corporate  database  at  the  top,  wing-level 
database  and  applications  at  the  middle  level.  The  user  level  resides  in  each  of  the  sub 
areas  of  the  wing  structure.  Functionally,  C2IPS  is  the  wing  corporate  database.  The 
three-tier  COE  drives  this  target  structure  and  implies  that  AMC  C4I  structures  should  be 
three  tier  as  well.  As  the  premier  AMC  C4I  system,  C2IPS  has  roles  in  this  structure  at 


all  three  levels  and  thus  it  needs  to  be  three  tier  also.  Right  now,  C2IPS  functions  mostly 
at  the  top  and  the  bottom  tiers;  full  COE  and  target  architecture  compliance  requires 
C2IPS  to  perform  more  middle  tier  functions. 
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Figure  1:  AMC  Target  C4I  Systems  Architecture  (AMC,  1996:4-48) 
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In  the  business  world,  many  companies  are  faced  with  the  same  information 
challenges  as  AMC.  In  business  terms,  Baum  (1996:45)  defines  the  three  layers  as  data, 
logic,  and  user  interface.  The  three  layers  “operate  as  distinct  entities  that  administrators 
can  place  on  different  platforms  and  locations.”  The  World  Wide  Web  (WWW)  is  a 
prominent  example  of  this  structure.  Users  send  their  requests  for  information  with  an 
internet  browser  to  a  web  server.  The  web  server  in  turn  answers  the  request  if  it  has  the 
necessary  data,  or  it  formats  and  advances  a  high-level  request  to  a  mainframe  or  large 
server  for  information  it  does  not  have.  An  architectural  advantage  to  three-tier  is  that 
each  separate  tier  can  be  modified  without  modifying  the  entire  system.  In  other  words, 
programming  changes  at  the  middle  level  should  not  require  client  tier  changes. 

The  servers  at  the  mid-level  tier  act  as  “data  warehouses.”  Sears  Roebuck  built  a 
1.7  terabyte  data  warehouse  to  improve  customer  service  in  its  information  systems 
division  by  integrating  disparate  data  sources  and  business  rules  (Greenberg,  1996). 
Rather  than  directly  querying  one  of  several  large  systems  over  the  wide  area  network,  the 
user’s  request  can  now  be  frequently  answered  with  data  out  of  the  “warehouse.”  Sears 
effectively  used  the  concept  to  cut  response  time  for  marketing  information  from  hours  to 
seconds.  Longs  Drug  Stores  recentiy  implemented  a  multi-tier  pharmacy  workflow 
system  because  they  found  that  “two-tier  technology  did  not  deliver  the  scalability  and 
future  growth  requirements  dictated  by  its  decentralized  management  structure”  (“A  long 
term  solution,”  1996). 

The  client  echelon  is  at  the  individual  workstation  where  the  information  is 
consumed  and  entered.  Fast  conununication  is  necessary  between  this  level  and  the 
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middle  level  to  maintain  adequate  response  time.  As  mentioned  above,  high  speed  local 
connections  are  cheaper  and  more  reliable  than  WAN  connections.  Thus,  the  mid-level 
servers  act  as  distribution  centers  that  are  designed  to  maintain  a  certain  level  of  customer 
service  and  response  time. 

Another  reason  to  locate  the  mid-level  servers  at  each  base  is  because  each  unit 
has  different  rules  and  requirements.  These  unit  specifics  are  referred  to  as  business  rules 
in  the  business  information  systems  vernacular.  Locating  these  on  the  base-level  servers 
ensures  that  all  users  at  that  base  use  the  same  rules,  and  that  the  base  can  modify  those 
rules  and  requirements  as  necessary  to  perform  its  unique  mission.  In  the  current  C2IPS 
architecture,  the  business  rules  or  mission  area  applications  (in  COE  speak)  that  exist  are 
spread  about  on  the  individual  workstations  or  directed  from  systems  above. 

To  minimize  single  points  of  failure,  the  three-tier  model  can  use  multiple  servers 
at  each  base  for  redundancy.  Replication  allows  users  to  continue  to  access  data  and 
conduct  business  without  interruption  in  the  event  of  a  server  failure  or  the  failure  of 
some  communications  links.  This  is  a  nice  feature,  especially  if  it  is  seamless  and 
invisible  to  the  user.  This  is  probably  the  biggest  reason  why  a  collection  of  servers  is 
now  preferred  over  mainframe  computers  at  the  middle  level.  The  server  collection  can 
provide  redundancy  and  most  importantly,  scalability  over  a  mainframe  implementation, 

Scalability  is  important  because  wing  missions  can  change  in  size  and  scope 
rapidly.  With  a  mainframe,  base  may  have  to  replace  the  machine  to  expand  its  capability 
enough  to  handle  its  new  mission.  With  a  server  based  system,  the  base  simply  needs  to 
add  more  servers  to  accept  the  increased  load. 
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Under  the  COE,  the  DOD  term  for  such  replication  and  robustness  is  called  the 
“Distributed  Computing  Environment,”  or  DCE.  Most  large  commercially  available 
database  packages  implement  DCE  to  eliminate  most  single  point  of  failure  problems  in 
mission  critical  applications.  Thus,  DCE  exists  in  a  fairly  “open”  format  from  most 
database  software  companies. 

C2IPS  could  use  distributed,  commercially  available,  “open”  systems  instead  of 
the  current  “hard  coded,”  contractor  developed  database  management  system.  The 
current  C2IPS  contractor.  Computer  Sciences  Corporation  (CSC)  has  demonstrated  what 
appears  to  be  three-tier  client/server  version  of  C2IPS.  While  they  have  offered  a  plan  to 
migrate  the  system  to  three-tier  client/server,  the  plan  does  not  fully  implement  all  of  the 
features  of  a  three-tier  client/server  system  and  some  functionality  may  be  lost  (Appel, 
1996). 

C2IPS  uses  customer  specific  interface  and  database  management  programs 
runmng  on  top  of  an  “Oracle”  brand  database.  The  CSC  proposal  involves  using  many  of 
the  same  specially  built  routines  that  are  already  in  use.  On  the  surface,  it  may  appear  to 
make  sense  to  reuse  existing  code.  In  reality,  however,  this  use  is  mostly  because  of 
system  limitations  imposed  by  the  data  distribution  architecture.  In  the  CSC  design, 
workstation  databases  are  still  “refreshed.”  In  other  words,  some  data  is  stiU  stored  on  the 
workstation.  This  differs  from  the  three-tier  client/server  distribution  that  has  data  only 
on  the  servers  and  it  does  not  fully  comply  with  standard  DCE  protocols.  Sticking  to  this 
architecture  diverges  from  the  stated  goal  of  using  commercial-off-the-shelf  (COTS) 
software  to  the  maximum  extent  possible  and  it  may  well  increase  costs  in  the  long  run. 
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If  CSC  increased  use  of  standard  commercially  available  application  toolkits,  much  of  the 
low-level  programming  and  testing  would  already  be  done.  Furthermore,  application 
developers  who  use  toolkits  like  “Powerbuilder”  and  the  like  are  readily  available.  With 
standard  toolkits,  new  progranuners  can  be  brought  up  to  speed  quickly  without  much 
specialized  C2IPS  low-level  programming  training.  The  CSC  proposal  does  not  go  far 
enough  when  it  come  to  using  COTS  software;  CSC  needs  to  use  standard  toolkits  to 
maximum  extent  possible.  With  true,  standardized  three-tier  client/server,  each  layer  can 
be  separately  modified  and  the  standardized  toolkits  would  aid  this  process.  Changes  at 
each  level  would  be  less  likely  to  break  appUcations  running  at  another  level.  As  a  result, 
application  development  and  prototyping  would  be  faster  and  much  less  expensive 
(Appel,  1996). 

AMC’s  stated  C4I  systems  modernization  goals  include: 

Develop  and  implement  flexible,  modular  system  architectures, ...,  use 
“open”  systems  to  maximize  interoperability,  use  distributed  processes  to 
assure  information  availability, ...,  assure  distributed  redundant  data  for 
survivability, ...,  assure  individual  customer  tailoring  of  information 
resources, ...,  utilize  standard  user  interfaces.  (AMC,  1996:4-46) 

By  properly  implementing  a  three-tier  client/server  architecture,  AMC  can 

improve  the  effectiveness  of  the  C2IPS  system  and  meet  all  of  these  goals.  Three-tier 

puts  the  data  and  logic  close  enough  to  the  users  that  they  get  good  response,  reliability 

and  adaptabihty.  At  the  same  time,  each  workstation  no  longer  needs  such  high  storage 

and  computational  capability.  Additionally,  many  COTS  application  development 

toolkits  are  now  available  that  make  the  three-tier  model  easy  to  program  and  modify. 

AMC  must  not  only  implement  three-tier,  but  it  must  ensure  that  the  contractor  must 
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implement  that  three-tier  in  ways  consistent  with  the  COE  and  good  business  practices  if 
it  wishes  to  meet  its  modernization  goals.  C2IPS  must  use  “standard”  three-tier 
client/server,  DCE  and  application  development  toolkits  if  it  is  to  interoperate  with  other 
systems  that  do  comply  with  COE. 
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III.  THIN  CLIENT 


The  “thin  chent”  concept  involves  putting  the  heavy  number  crunching  and  data 
storage  capability  on  the  mid  and  high  level  servers,  rather  than  at  the  lower  echelon 
client.  While  the  three-tier  client/server  architecture  specifies  the  layers  of  the  system,  it 
is  not  that  specific  about  how  much  computing  occurs  at  each  level.  The  thin  client 
concept  requires  putting  only  minimal  capability  at  each  workstation.  After  some 
discussion  of  die  inherent  efficiencies  and  problems  of  the  thin  client,  the  study  will 
center  on  whether  the  thin  client  concept  has  any  bearing  on  improving  C2IPS 
functionality. 

Right  now,  each  C2IPS  workstation  is  a  pretty  expensive  piece  of  hardware 
because  it  needs  to  perform  heavy  database  chores  that  would  bring  a  lesser  computer  to  a 
crawl.  If  a  thin  client  concept  was  implemented,  the  workstation  would  merely  perform 
display  and  query  duties.  Each  client  computer  could  be  much  less  powerful  and  less 
expensive  yet  still  provide  timely  and  accurate  information  retrieved  from  the  mid-level 
servers.  These  servers  would  require  essentially  the  same  computing  power  that  the 
current  workstations  do  because  they  would  be  performing  almost  exactly  the  same 
database  functions  as  the  current  workstations.  The  mid-level  servers  would  have  to  deal 
with  many  requests  for  information  from  clients,  but  much  of  this  additional  load  is 
balanced  by  eliminating  the  workload  imposed  by  user  interaction  on  that  specific 
machine.  In  other  words,  a  server  doesn’t  have  to  produce  the  fancy  output  for  the  user 
and  await  every  user  input,  while  the  client  workstation  does.  The  server  is  free  to  do 
database  work,  high-level  server  interaction,  and  answering  client  workstation  queries. 
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Database  replication  in  a  DCE  can  involve  considerable  network  overhead. 
However,  all  the  workstations  in  the  current  C2IPS  design  must  synchronize  their 
databases  to  maintain  adequate  replication,  so  the  situation  is  no  better.  At  some  bases, 
this  means  75  or  80  different  machines  have  to  maintain  synchronization  of  their 
databases.  In  a  three-tier  client/server  system,  the  same  base  might  have  three  or  four 
servers  to  provide  redundancy  and  adequate  response  time  (Appel,  1996).  Now  there 
would  only  be  those  three  or  four  servers  synchronizing.  Obviously,  the  traffic  from  the 
thin  client  workstations  would  offset  this  savings  as  every  request  for  information  must 
go  to  a  server.  The  point  here  is  that  a  properly  designed  system  should  not  significantly 
increase  network  bandwidth  requirements. 

By  moving  the  business  rules  and  data  to  the  mid-level  server  level  under  a  three- 
tier  client/server  architecture,  a  high  speed  response  can  be  maintained  while  the 
requirement  for  a  large  database  system  at  each  workstation  can  be  eliminated.  The  thin 
client  concept  involves  moving  all  the  data  one  step  up  the  hierarchy  to  reduce  the 
footprint  required  at  each  workstation.  With  reduced  client  computing  requirements,  the 
client  workstations  could  now  be  inexpensive  personal  computers  (PCs).  These  PCs  are 
generally  already  in  place  in  almost  any  location  where  C2IPS  might  have  a  terminal. 
Many  C2IPS  workstations  sit  right  next  to  a  PC  that  the  user  uses  for  all  the  other  tasks 
that  C2IPS  does  not  perform.  These  tasks  include  using  databases,  word  processors, 
spreadsheets.  Email,  and  numerous  other  productivity  software  applications.  Simply  put, 
if  C2IPS  could  use  thin  client,  no  special  workstations  or  additional  equipment  would  be 
required  because  C2IPS  could  use  regular  PCs.  The  PCs  required  already  exist  in  the 
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workplaces  where  C2IPS  is  in  use.  In  the  extreme,  there  would  be  no  workstation 
expense  at  all  and  C2IPS  money  could  instead  be  put  to  use  on  servers  and  software. 

Again,  the  biggest  obstacle  to  thin  client  use  may  be  how  it  is  implemented.  Poor 
software  design  may  overload  networks  with  frequent  information  requests.  Properly 
implemented,  however,  the  thin  client  concept  could  well  leverage  the  capabilities  of 
existing  systems  without  unnecessarily  bogging  down  the  network  infrastructure. 
Furthermore,  infrastructure  could  be  expanded  as  necessary  to  fill  the  requirement. 
Numerous  AMC  infrastructure  initiatives  are  already  in  place  to  improve  network 
capacity  so  that  it  can  handle  video  and  other  high  bandwidth  data  streams.  Especially 
with  the  replication  differences  discussed  earlier,  C2IPS  thin  client  loads  would  not 
appreciably  affect  such  reasonably  robust  networks. 

An  excellent  refinement  to  the  thin  client  concept  is  emerging  in  the  business 
world.  Many  businesses  are  saving  money  by  not  writing  specific  client  software  to 
interface  with  the  mid  and  high  level  servers,  but  are  instead  standardizing  on 
conunercially  available,  client  front  end  software.  In  the  process  of  re-engineering  their 
systems,  they  are  reconfiguring  the  servers  to  answer  requests  in  a  format  that  any  internet 
browser  such  as  Netscape  Navigator  or  Microsoft  Internet  Explorer  can  display.  Not  only 
are  they  switching  to  the  three-tier  client/server  hierarchy,  but  they  are  outsourcing  the 
lowest  level  by  using  COTS  client  software  without  modification.  Basically,  anybody 
with  the  correct  access  passwords  can  get  the  information  through  the  use  of  readily,  and 
inexpensively  available,  internet  browser  software.  They  simply  open  Navigator,  log  into 
the  system  and  do  their  work. 
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The  benefits  of  using  a  standardized  browser  have  not  gone  unnoticed.  The 

Defense  Information  Systems  Agency  (DISA)  is  the  agency  with  overall  responsibihty  for 

unifying  DoD  information  systems  standards.  DISA  recently  purchased  a  180,000  copy 

user  license  for  Netscape  Navigator: 

DISA  plans  to  use  Navigator  to  plan,  manage,  and  execute  military 
operations  worldwide,  placing  Navigator  at  the  heart  of  the  U.S.  military 
communications  system.  DISA  will  use  Netscape’s  technology  to  manage 
operational  logistics,  transport,  and  medical  support.  (Balderston, 

1996b:  16) 

Some  may  argue  that  the  web  architecture  requires  significant  additional  overhead 
as  Hypertext  Transfer  Protocol  (HTTP)  clients  constantly  establish  and  break  connections 
with  their  servers.  This  is  a  real  concern,  as  many  servers  may  have  very  heavy 
workloads  that  could  dampen  the  usefulness  of  the  simple  web  model.  The  development 
of  the  Internet  Inter-Object  Request  Broker  (ORB)  Protocol  (HOP),  however,  will  reduce 
this  impact  of  using  the  web  because  HOP  maintains  connections  between  servers  and 
clients,  where  HTTP  does  not.  Netscape  Communications,  a  leading  internet  browser 
and  server  software  company  is  working  to  integrate  this  technology  into  future 
generation  software,  because  it  minimizes  the  server  loads  that  occur  when  many  clients 
must  constantly  reestablish  links  just  to  view  different  pages  of  information  on  the  same 
server  (Petreley,  1996).  Furthermore,  it  will  also  substantially  reduce  bandwidth 
requirements  because  it  involves  sending  only  messages  between  the  applications  running 
on  the  server  and  the  client,  versus  sending  entire  web  pages  (Balderston,  1996a:40). 
While  much  of  this  lies  in  the  future,  many  corporate  networks  are  already  experiencing 
significant  cost  reductions  and  minimal  problems  with  web  based  networks. 
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The  current  limitations  of  web  based  client  models  however,  make  a  complete 
switch  to  the  web  impractical.  Most  web  based  input  and  query  forms  are  very  limited 
compared  to  what  a  full  fledged  client  can  provide.  This  is  both  because  of  security 
limitations  and  immature  web  technologies.  Most  similar  and  recent  web 
implementations  provide  only  simple  and  limited  interfaces  to  corporate  databases.  An 
example  of  military  web  usage  is  the  Global  Transportation  Network  (GTN).  GTN  is 
designed  to  provide  users  of  the  Defense  Transportation  System  with  visibility  into  the 
movements  of  materiel  and  personnel,  much  like  FedEx  and  United  Parcel  Service  do 
through  their  information  systems.  As  a  three-tier  client/server  system,  GTN  servers 
interface  with  numerous  systems  and  act  as  data  warehouses  to  provide  timely  tracking 
information  to  client  machines.  Normal  GTN  client  software  requires  about  200 
megabytes  of  PC  disk  drive  space  and  is  capable  of  generating  complex  queries  and 
reports.  While  this  client  software  is  somewhat  “thin”  because  no  data  is  stored  on  the 
client,  it  is  still  a  large  piece  of  software.  Compared  to  C2IPS,  however,  it  is  very  ‘thin’; 
it  will  run  on  most  desktop  computers  in  use  today. 

Many  users  have  only  minimal  need  to  access  GTN.  For  simple  queries  and 
reports,  GTN  has  a  web  based  presence  that  any  user  with  a  reasonably  current  version  of 
an  internet  browser  and  account  can  access.  As  a  whole,  GTN  is  still  a  read-only  display 
type  system  and  the  web  interface  fulfills  the  needs  of  occasional  users  very  well. 
Frequent  and  power  users,  however,  would  find  the  web  interface  too  inflexible,  slow, 
and  limited  for  their  needs.  Thus,  GTN  uses  both  browser  and  full  client  interfaces  where 
appropriate  (JOPES  Training  Organization,  1996). 
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CSC  has  developed  such  a  limited  use  web  service  for  C2IPS.  AMC  is 
developing  a  statement  of  work  that  will  be  incorporated  into  the  existing  contract  for 
read-only  web  client  access  to  C2IPS.  This  added  functionality  should  be  pursued.  It 
would  help  meet  Appel’s  desire  to  provide  more  C2IPS  connectivity  around  the  base 
(1996).  Some  base  agencies  that  are  currently  excluded  from  C2IPS  for  cost  reasons 
could  now  access  the  system  whenever  necessary.  An  excellent  example  of  a  potential 
user  is  the  base  billeting  office;  they  could  check  base  inbound  aircraft  data  for  room 
requirements.  Right  now,  crewmember  names  are  manually  faxed  from  the  base 
command  post  to  the  billeting  office.  The  web  interface  could  ehminate  this  need  and  the 
manpower  requirements  associated  with  it. 

The  CSC  web  implementation  appears  to  be  well  conceived.  The  current  plan  is 
to  use  current  web  protocols,  and  user  authentication  and  audits  for  security.  Web  access 
would  be  a  read-only  subset  of  C2IPS  displays.  The  intent  of  the  system  is  to  provide 
both  C2IPS  online  documentation  and  low  level  user  interface  capability.  AMC  intends 
to  maintain  both  “Basic  and  Web-Based”  user  interfaces  as  necessary  to  serve  the  needs 
of  all  users  (AMC/DOU,  1996a:2-41). 

Obviously,  the  web-based  client  in  this  case  is  not  going  to  hold  any  local  data. 
What  remains  to  be  seen  is  whether  CSC  will  move  all  the  data  and  business  rules  on  the 
basic  interface  machines  up  to  the  server  level  as  well.  The  thin  client  concept  would 
require  this,  but  the  current  CSC  proposal  still  shows  some  data  residing  at  the  client 
level.  If  the  amount  of  data  at  the  client  level  is  high  enough,  the  requirement  for  a 
dedicated,  high-performance  workstation  will  remain  valid.  Aside  from  reusing  the 


21 


legacy  client  machines,  this  is  not  a  good  idea  as  the  C2IPS  project  would  then  still  be  in 
the  workstation  business.  C2IPS  should  implement  the  thin  client  concept  to  reduce 
program  costs  associated  with  the  purchase  of  expensive  and  redundant  workstations. 

With  the  use  of  existing  PCs,  the  local  C2IPS  footprint  could  effectively  go  to 
nearly  zero.  Through  three-tier  client/server  with  a  thin  client  approach,  regular  PCs 
would  make  excellent  C2IPS  workstations.  AMC  intends  to  switch  to  using  only 
government  furnished  workstations  as  soon  as  possible  (AMC/DOU,  1996a:2-25).  The 
only  significant  workstation  cost  would  then  be  the  software  and  its  training  and 
maintenance,  since  the  PCs  already  exist.  No  other  special  software  or  workstations 
would  be  required. 

In  addition,  a  web  based  C2IPS  presence  would  allow  more  users  to  access  C2IPS 
data  on  an  occasional  basis.  The  only  cost  for  this  would  be  the  web  server  and  its 
software;  most  computer  users  today  are  familiar  with  browser  operation,  so  training 
costs  are  minimal  as  far  as  the  client  software  is  concerned  and  the  browsers  are  available 
for  free  (AMC,  1996:4-42). 

The  thin  client  concept  could  both  reduce  costs  and  improve  system  usability. 
Thus,  it  warrants  serious  consideration  as  an  area  for  improving  C2IPS  overall  cost 
effectiveness. 
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IV.  DATA  NETWORK  IMPROVEMENTS 


The  third  C2IPS  study  area  is  the  data  network  that  underlies  the  whole  system. 

As  a  command  and  control  system,  C2IPS  needs  highly  reliable  and  fast  data 
communications.  Whether  this  component  is  adequate  to  support  both  local  and  wide 
area  network  requirements  is  the  center  for  discussion.  At  C2IPS  fixed  nodes  (permanent 
installations)  the  network  infrastructure  functions  reasonably  well,  but  there  may  be  ways 
to  cut  costs  or  improve  the  system.  Most  of  the  wide  area  network  support  is  outside  the 
scope  of  C2IPS  because  it  is  supplied  by  the  DOD.  This  in  mind,  this  study  will  examine 
wide  area  improvements  that  could  improve  deployed  node  connectivity  when  regular 
services  are  not  available.  These  two  issues  will  be  discussed  separately  for  clarity. 

Fixed  Node  Infrastructure 

While  the  original  C2IPS  need  for  a  data  network  probably  required  private 
circuits,  better  capabiUty  now  exists  elsewhere.  Originally,  C2IPS  nodes  required 
dedicated  fiber-optic  lines  to  connect  workstations  because  of  lacking  base 
communications  infirastructures  (Screnci,  1996).  Rather  than  running  special  C2IPS  data 
lines  around  the  base,  that  same  money  could  now  be  spent  on  building  generic  local  base 
infrastructure  that  is  capable  of  supporting  C2IPS  and  other  needs.  In  this  way,  the  data 
network  can  be  used  for  other  purposes,  and  the  resultant  poohng  of  resources  from 
C2IPS  and  the  dozens  of  other  programs  that  would  benefit  would  allow  the  construction 
of  extensive  common  local  networks.  These  robust  and  very  fast  networks  could  be 
shared  by  all  the  units  on  the  base  and  could  conceivably  carry  any  type  of  traffic. 


23 


AMC’s  target  C4I  system  architecture  includes  a  “shared  common 
communications  processor  for  all  external  access,"  “access  from  any  terminal  on  the 
network  to  all  data  and  software  functionality  (within  authorized  use  and  need-to-know 
parameters)”,  and  “a  common  high  speed  multi-media  transport  utility”  (AMC,  1996:4- 
47).  As  AMC  progresses  toward  meeting  these  needs,  C2IPS  can  leverage  the 
capabilities  as  they  become  available. 

According  to  Screnci  (1996),  C2IPS  is  now  moving  to  use  more  base 
infrastructure  capability  as  that  infrastructure  becomes  available.  The  immediate  benefit 
here  is  that  C2IPS  nodes  can  be  added  and  relocated  without  calling  in  a  C2IPS  install 
team.  Furthermore,  as  the  network  hardware  becomes  more  standardized,  support 
becomes  easier  and  client  computer  systems  are  no  longer  so  tied  to  one  specific  platform 
(Heitman,  1996).  Rather  than  dedicated  C2IPS  maintenance,  most  maintenance  would  be 
generic  LAN  maintenance  performed  by  the  base  communications  squadron. 

Currently,  additional  C2IPS  terminals  require  install  teams  to  run  the  dedicated 
fiberoptic  lines  required.  Many  base  communications  infrastructures  are  now 
approaching  the  capacity  and  pervasiveness  where  the  C2IPS  network  is  no  longer 
necessary.  Users  could  move  and  install  their  own  C2IPS  terminals  by  simply  plugging 
the  machine  into  their  LAN.  Even  more,  if  the  aforementioned  thin  client  concept  was 
implemented,  there  would  be  no  C2IPS  “terminals”  per  se;  users  could  install  the  C2IPS 
client  software  on  their  own  desktop  PC  with  minimal  assistance. 

On  a  common  data  network,  base  communication  personnel  could  monitor, 
maintain  and  enhance  the  network  as  necessary  to  ensure  connectivity.  The  common 
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network  offers  significant  economies  of  scale  and  consolidation  of  resources.  When  each 
system  has  its  own  conununications  infrastructure,  there  are  more  possible  compatibiUty 
problems  and  the  expense  associated  with  backup  systems  often  means  that  they  will  not 
be  implemented.  The  AMC  goal  of  a  common  backbone  with  a  common 
communications  processor  gives  those  economies  of  scale  and  it  allows  AMC  to  build  a 
compatible,  command-wide  backup  communications  system. 

In  the  case  of  C2IPS,  the  communications  processor  is  a  C2IPS  asset  maintained 
by  C2IPS  system  administrators.  Most  bases  have  only  one.  The  target  common 
communications  processor  would  belong  to  the  base  and  would  theoretically  be 
maintained  by  the  base  communications  unit.  The  base  communications  unit  is  normally 
equipped  to  provide  24  hour  service  and  support  for  infrastructure.  With  a  conunon 
communications  processor  not  only  would  acceptable  support  be  already  available,  but 
alternate  processors  could  be  maintained  for  the  entire  base,  thereby  ensuring 
connectivity. 

Rather  than  having  dozens  of  underutilized  data  networks  strung  about  the  base, 
everyone  shares;  they  consolidate  their  data  traffic.  By  consolidating,  everyone  gets  a 
faster,  more  reliable  and  redundant  network  for  less  money.  Additionally,  the  costs  of  the 
network  are  no  longer  directly  attributable  to  the  individual  systems  that  use  them. 
Instead,  they  would  be  “funded  through  a  wholesale  MAJCOM  infrastructure  tax”  (AMC, 
1996:4-39).  In  the  case  of  C2IPS,  the  program  would  only  have  to  pay  for  servers  and 
software  if  conunon  communication  equipment  were  used  instead  of  the  dedicated  fiber 
lines. 
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The  progress  to  date  on  using  common  data  networks  should  continue,  and  if 
possible,  it  should  be  accelerated.  Common  LANs  and  MANs  reduce  support  and 
equipment  costs  through  economies  of  scale  and  consoUdation. 

Deployed  Node  Connectivity 

In  the  wide  area,  much  of  the  C2IPS  traffic  already  travels  on  these  conunon 
networks.  Between  established  bases,  C2IPS  data  generally  travels  over  the  shared  the 
Defense  Information  Systems  Network  (DISN),  formerly  known  as  the  Defense  Data 
Network  (DDN),  and  is  it  consolidated  with  other  data  streams.  This  use  of  existing 
communications  capability  should  continue  because  the  cost  of  dedicated  C2IPS  high¬ 
speed  lines  would  be  exorbitant  when  the  required  capability  already  exists  in  DISN.  The 
speed  and  reliability  of  DISN  is  improving  on  a  daily  basis  and  its  availability  is  good 
(AMC,  1996:4-36). 

A  special  case  exists,  however,  when  deploying  C2IPS  to  forward  locations.  In 
most  air  mobility  deployments,  a  Tanker/Airlift  Control  Element  (TALCE)  is  the  first 
unit  on  the  ground.  It  coordinates  the  arrival  and  service  of  aircraft  delivering  personnel 
and  equipment  to  their  deployed  locations.  Most  TALCE  teams  have  deployable  C2IPS 
packages.  Unfortunately,  C2IPS  barely  functions  using  the  communications  systems  that 
are  initially  available  in  field  conditions.  Often,  TALCE  communications  may  consist  of 
a  single  poor  quality  telephone  line.  Most  TALCE  leaders  consider  C2IPS  a  waste  of 
time,  money,  and  most  importantly,  space  on  an  airplane  because  “C2IPS  doesn’t  work 
without  dedicated  comm”  (Groff,  1996). 
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Deployed  C2IPS  serves  a  different  role  than  does  fixed  C2IPS.  Rather  than 
coordinating  functions  around  the  wing  (since  the  ‘wing’  structure  may  consist  of  only  a 
handful  of  people),  deployed  C2IPS  is  more  for  communication  with  the  outside  world. 

At  the  same  time,  the  deployed  TALCE  may  have  use  for  some  C2IPS  functionality, 
especially  if  the  operation  increases  in  size.  Thus,  TALCE  teams  still  need  C2IPS,  but 
C2IPS  needs  to  fill  their  requirements  better.  The  primary  considerations  here  are  that 
C2IPS  provide  a  small,  rapidly  available,  reliable  and  fast  connection  back  to  AMC  and 
the  rest  of  the  world. 

Suitable  land  lines  to  effectively  support  deployed  C2IPS  take  time  to  arrange. 

The  difficulty  of  arranging  suitable  land  lines  for  a  TALCE  cannot  be  overemphasized. 
Many  countries  simply  do  not  have  the  capability  to  begin  with,  or  some  connections  may 
have  to  pass  through  many  different  entities  before  they  get  to  anything  resembling  DISN. 
As  a  result,  dedicated  communications  lines  frequently  are  not  in  place  until  about  the 
time  the  TALCE  is  packing  its  gear  to  leave  for  home.  In  cases  where  the  lines  are 
available  quickly,  they  often  do  not  support  very  high  data  rates  or  they  are  highly 
unreliable.  In  addition,  establishing  these  lines  can  cost  thousands  of  dollars  in  setup  and 
installation  fees. 

For  a  TALCE,  there  is  no  time  to  establish  dedicated  communications  land  lines. 
Initially,  TALCEs  need  some  type  of  long-range  wireless  capability.  Most  of  the  current 
wireless,  long  range  communications  systems  used  by  AMC  are  wholly  inadequate, 
however,  for  the  amount  of  data  transfer  required  in  a  fully  integrated  and  functional 
command  and  control  system.  One  system  uses  HF  (high  frequency)  radios  to  transmit 


27 


data  at  approximately  100  bytes  per  second  over  great  distances  (Scheier,  1995).  While 
the  sophistication  of  these  radios  has  improved  in  recent  years,  the  basic  concept  is 
flawed  when  it  comes  to  a  modem  command  and  control  system.  Not  only  is  HF 
frequently  very  garbled,  but  the  garble  further  reduces  an  already  far  too  low  data  rate  to 
the  point  where  the  C2IPS  node  is  effectively  cut  off  from  the  rest  of  the  world. 

According  to  Cesar  (1995:19),  much  of  the  problem  arises  because  these  communications 
architectures  are  designed  for  person  to  person  (PtP)  information  exchanges.  He  asserts 
that  computer  to  computer  (CtC)  data  exchanges  should  not  use  architectures  designed  for 
PtP  because  “PtP  architectures  are  technically  suboptimal  for  CtC  uses,”  operators  can 
intervene  and  delay  information,  and  because  machines  can  automatically  exchange  large 
volume  of  data  with  other  machines  at  much  faster  rates  than  humans.  By  using  a  PtP 
based  system  like  HF,  an  automated  system  like  C2IPS  is  hobbled. 

There  is  some  military  satellite  communication  (MILSATCOM)  capability 
available  for  C2IPS  use,  but  it  is  limited  in  availability  and  it  only  supports  9600  kilobits 
per  second  maximum  data  rates.  While  military  satellite  capability  is  constantly 
improving,  the  demands  upon  that  system  are  also  increasing  as  more  users  access  the 
network. 

What  deployed  C2IPS  needs  is  a  truly  suitable  portable  communications  system. 

In  this  instance,  it  may  require  long  term  leasing  of  commercial  satellite  capability  or  the 
use  of  other  military  satellite  data  links  as  necessary.  Rather  than  pulling  wires  and 
arranging  connectivity  through  local  phone  exchanges  to  connect  the  site,  an  effective 
implementation  of  an  enhanced  deployable  C2IPS  node  could  use  a  simple,  easy-to-aim 
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satellite  dish.  In  this  way,  a  deployed  node  could  be  up  and  running  in  a  few  minutes. 
Even  though  the  satellite  time  costs  several  dollars  per  minute,  overall  effectiveness  of 
the  system  would  improve  enough  to  warrant  the  increased  cost.  After  all,  when  an  hour 
of  wasted  aircraft  flying  time  can  easily  exceed  $10,000  (depending  on  the  type  of 
aircraft),  a  well  connected  TALCE  may  be  worth  the  expense  of  a  satellite  connection. 

By  leveraging  existing  satellite  capabiUties,  C2IPS  forward  deployed  capability 
will  improve.  During  Operation  Joint  Endeavor,  the  U.S.  Army  fielded  55  super-high- 
frequency,  multi-chaimel  ground  satellite  terminals  and  only  nine  leased  high  speed  land 
hnes.  The  system  used  “a  combination  of  DoD,  NATO,  and  commercial  satellites” 
(Constance,  1996).  The  combination  of  parallel  systems  eliminated  single  points  of 
failure  and  provided  enough  bandwidth  that  commanders  were  able  to  “conduct  daily 
videoconferences  without  compromising  routine  traffic”  (Constance,  1996). 

AMC  is  working  hard  to  fix  the  communication  problem.  The  AMMP  states  that 
AMC  is  well  into  acquiring  15  Theater  Deployable  Communications  (TDC)  units,  but 
funding  is  limited  (4-30).  According  to  Bouquet,  eleven  of  these  units  are  set  to  go  to  Air 
Mobility  Operations  Groups  and  the  remaining  four  will  go  to  Tanker  Task  Force  units. 
Both  of  these  types  of  units  are  AMC  assets  that  are  designed  to  deploy  command  and 
control  capability  into  the  field.  TDC  packages  are  fairly  large  and  are  designed  to 
provide  complete  local  phone  and  data  network  systems,  and  outside  connectivity  through 
a  2.4  meter  satelUte  dish.  The  satellite  subsystem  is  capable  of  communicating  on  the 
military  X  band,  or  the  commercial  C  and  Ku  bands  as  necessary.  TDC’s  will  effectively 
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fill  AMC  large  unit  deployable  communications  needs.  C2IPS  could  easily  ride  along  on 
its  1.5  megabit  per  second  data  rate  (Bouquet,  1996). 

AMC  will  still  have  a  significant  shortfall  in  satellite  capabihty  for  smaller 
deployed  units  for  the  near  future.  TDC  packages  are  inappropriate  for  the  majority  of 
deployed  AMC  operations  because  of  their  size.  AMC  recently  acquired  40 
INMARSAT-B  terminals  to  fill  some  of  the  gap,  but  the  intent  of  the  terminals  is  mostly 
to  improve  voice  conununications  between  deployed  TALCEs  and  the  headquarters.  The 
briefcase-sized  terminals  are  commercially  available  and  cost  $25,000  apiece.  The  device 
takes  a  minimally  trained  user  about  two  minutes  to  assemble.  Service  costs  $2.85  per 
minute  to  call  from  anywhere  in  the  world  to  anywhere  in  the  world.  Realistically,  the 
rates  are  not  significantly  more  expensive  than  regular  international  phone  calls. 
Furthermore,  these  terminals  are  equipped  with  a  serial  port  for  data  and  are  capable  of 
reliably  transmitting  single  channel  ISDN  (Integrated  Services  Digital  Network)  at  64 
kilobits  per  second.  With  the  addition  of  suitable  network  hardware  the  terminal  could 
effectively  increase  C2IPS  and  other  data  system  throughput  considerably  (Bouquet, 
1996).  A  well  designed,  conunercially  available  ISDN  router  could  be  programmed  to 
quickly  connect  whenever  necessary  to  allow  the  C2IPS  system  to  update  its  database 
with  the  AMC  corporate  database.  Such  a  setup  would  allow  the  TALCE  to  have  current 
information  while  keeping  satellite  costs  low.  AMC  has  plans  to  connect  C2IPS 
deployed  nodes  via  INMARSAT,  but  it  appears  to  be  mostly  a  backup  system.  The 
capabilities  of  the  INMARSAT-B  terminals,  however,  indicate  that  INMARSAT  may  be 
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well  suited  for  an  initial  communication  link  capability.  It  is  very  portable,  reliable  and 
portable. 

As  a  command  and  control  system  with  a  requirement  for  up  to  the  second  data, 
C2IPS  needs  superior  network  speed  and  reliability.  In  the  case  of  deployed  C2IPS,  the 
expense  of  high  speed,  high  quality,  satellite  data  links  is  justified.  Better  network 
capability  will  improve  the  data  currency  and  lower  AMC’s  actual  operations  costs 
through  the  effective  use  of  that  current  information. 
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V.  ADDED  FUNCTIONALITY 


Finally,  one  only  has  to  visit  an  aerial  port,  command  post,  or  current  operations 
shop  to  see  a  plethora  of  “stovepipe”  information  systems  that  all  perform  individual 
functions.  An  average  current  operations  shop  may  have  to  access  and  enter  data  into 
seven  different  but  similar  systems.  Much  of  the  data  is  identical  to  the  data  entered  into 
other  systems.  In  fact  much  of  the  day  may  involve  reconciling  differences  between 
systems  or  entering  redundant  information.  The  reason  for  much  of  this  is  that  each  of 
these  separate  systems  was  separately  developed  and  funded  by  the  command  to  perform 
a  specific  purpose.  The  resultant  duplication  of  effort  and  confusion  is  substantial.  As 
the  overarching  wing  level  command  and  control  system,  C2IPS  should  replace  many  of 
these  separate  systems  by  including  modules  that  perform  the  required  tasks  and 
transparently  interface  with  systems  at  the  command  level  as  necessary. 

While  the  list  of  smaller  systems  eligible  for  inclusion  is  potentially  quite  long, 
the  main  thrust  should  initially  be  towards  those  systems  that  directly  relate  to  operations. 
Maintenance  systems  like  G081  and  CAMS  are  too  large  to  warrant  more  than  simple 
interface  inclusion;  the  C2IPS  terminal  could  open  a  window  into  these  systems  and  some 
information  could  trade  between  servers.  The  systems  that  do  make  sense  to  integrate 
include  crew  scheduling  (CAASS),  aerial  port  operations  (APACCS  and  load  plan 
generators),  flight  scheduling  (ADANS  or  one  of  dozens  of  home  grown  systems), 
mission  history  (AHS  and  to  some  extent  AFORMS),  flight  plans,  airspace  reservation 
(ALTRVs  and  MASMS)  and  passenger  systems.  AMC  has  a  good  idea  of  what  is 
required  of  the  planning  and  scheduling  module,  but  C2IPS  is  still  a  long  way  from 
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accomplishing  what  was  originally  required  and  even  farther  from  meeting  the  most 
recent  requirements  list  (AMC/DOU,  1996c). 

Including  or  interfacing  these  types  of  systems  into  the  integrated  C2IPS 
environment  would  reduce  confusion  and  improve  information  flow.  All  of  these 
systems  share  information  with  C2IPS  and  usually  require  some  type  of  “sneaker-net”  or 
“finger-net”  to  exchange  data.  With  one  time  data  entry,  errors  and  manpower 
requirements  would  deerease.  Generating  reports  for  decision  makers  would  be  simpler, 
more  accurate  and  timely. 

A  large  hole  in  C2IPS  capability  is  the  planning  and  scheduling  module.  AMC  is 
now  considering  “Commercial  Off-the-Shelf  (COTS)  and/or  Government  software 
products  at  least  as  an  interim  solution”  because  “we  eannot  wait  for  another  two  years 
before  we  deliver  a  capability  to  our  wing  scheduling  and  current  operations  folks.” 
(AMC/DOU,  1996b:  1)  This  is  because  C2IPS  does  not  meet  current  planning  and 
scheduling  requirements  to  the  necessary  level  of  detail. 

An  exeellent  baseline  for  what  C2IPS  should  do  in  terms  of  planning  and 
scheduling  can  be  found  in  the  promotional  brochures  for  the  “Enhanced  Scheduling 
Program  2000”  (ESP-2000)  system  developed  by  Global  Technologies  International 
(GTI)  and  now  supported  and  marketed  by  Electronic  Data  Systems  (EDS).  The  initial 
grass-roots  concept  of  this  system  was  to  develop  a  universal  client  and  scheduling  tool 
for  all  the  headquarters  controlled  information  systems.  GTI  took  the  initial  inputs  and 
unilaterally  built  and  marketed  a  workable  system  to  aid  wings  in  their  scheduling  and 
controlling  functions.  The  intent  was  mostly  to  sell  the  software  to  those  units  that  had 
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no  C2IPS  capability.  AMC  is  now  testing  ESP-2000  as  a  parallel  system  to  C2IPS. 
Testing  will  eommence  at  Travis  Air  Force  Base  in  the  spring  of  1997  to  see  if  ESP-2000 
will  meet  the  requirements  of  actual  aircraft  scheduling  functions  and  to  see  how  it  can  be 
linked  to  C2IPS.  (Sullivan,  1997)  The  ESP-2000  concept  promises  to  provide  “single¬ 
point,  one-time  data  entry  of  mission  planning/scheduling  data  on  your  existing  PC’s” 
(GTI,  1996).  It  also  offers  “automatic  reporting  with  transparent  interfaces  to  major 
government  systems”  with  a  “user-friendly,  Windows  based  GUI  interface.”  (GTI,  1996) 
ESP-2000  would  replaee  CAASS,  and  all  the  homegrown  scheduling  systems.  The  ESP- 
2000  program  does  what  most  users  thought  C2IPS  should  be  able  to  do  because  it  was 
built  by  and  for  the  users.  As  such,  it  has  a  rapidly  growing  following  and  appears  to  be 
the  only  comprehensive  package  available  at  present  that  can  do  what  most  users  want. 

The  problem  with  ESP-2000,  however,  is  that  it  could  become  yet  another  system 
AMC  must  deal  with.  While  it  is  basically  a  three  tier  Client/Server  system  with  a  lot  of 
promise,  it  only  performs  certain  portions  of  the  overall  C2IPS  mission.  It  does  perform 
many  of  those  functions  better,  but  nonetheless,  it  performs  only  a  subset  of  C2IPS 
functions.  Implementing  both  systems  will  only  be  unnecessarily  redundant  and  wasteful. 

The  emphasis  should  not  be  on  developing  separate  systems  but  to  assimilate 
ESP-2000  funetions  into  the  overarehing  C2IPS  arehitecture.  In  other  words,  use  the 
ESP-2000  user  interfaee  for  certain  funetions  on  the  C2IPS  system.  This  should  be  a  high 
priority  because  C2IPS  is  the  system  slated  for  migration  into  the  higher  level  GCCS  and 
Theater  Battle  Management  Core  System  (TBMCS)  architectures,  while  ESP-2000  is  not 
even  on  the  map.  According  to  Appel  (1996),  CSC  should  use  the  ESP-2000  interfaee  for 
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many  of  its  functions  or  possibly  even  hire  GTI  to  build  the  interface  while  CSC 
concentrates  on  the  data  structure  and  infrastructure.  The  database  would  remain  the 
constant  to  support  the  standardized  processes  and  data  structures  required  for  GCCS  and 
TBMCS,  while  applications  could  be  developed  rapidly  in  response  to  user  requirements 
and  mission  changes. 

ESP-2000  type  functionality  would  extend  lower  into  wing  operations  than  C2IPS 
currently  does,  and  thus  would  open  the  system  up  for  more  use  and  better  information 
flow  within  the  wing. 

Outside  of  the  scheduling  and  execution  of  aircraft  sorties,  ESP-2000  does  not 
provide  much  capability.  Another  area  that  requires  better  automation  and  integration 
into  the  wing  command  and  control  system  are  all  the  aerial  port  functions.  The  aerial 
port  is  responsible  for  cargo  manifesting,  loading,  and  pallet  buildup.  They  also  perform 
aircraft  fleet  servicing  like  toilets,  food,  and  blankets.  At  enroute  locations,  these  same 
functions  are  performed  by  Air  Mobility  Support  Squadrons  (AMSS).  All  of  these 
functions  are  intricately  linked  to  the  aircraft  flying  schedule  and  other  wing  functions. 
Much  of  the  aerial  port  functions  are  automated  with  the  Aerial  Port  Automated 
Command  and  Control  System  (APACCS)  and  the  Consolidated  Aerial  Port  System  11 
(CAPS  n).  APACCS  and  CAPS  11  are  DOS  based  programs  that  have  some  bugs  and 
require  reentry  of  much  of  their  data  into  C2IPS.  These  programs  could  easily  be 
replaced  with  C2IPS  modules  that  would  streamline  the  flow  of  information  through  the 
aerial  port  and  feed  that  information  through  C2IPS  to  GTN.  C2IPS  nodes  are  already  in 
place  in  aerial  ports  and  AMSS  units,  so  adding  these  modules  makes  practical  sense 
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because  they  would  eliminate  transfer  errors  and  duplication  of  effort.  In  addition,  their 
inclusion  would  eliminate  all  the  system  maintenance  and  workstation  requirements 
associated  with  these  additional  systems. 

According  to  U.S.  Transportation  Conunand’s  Defense  Intransit  Visibility 
Integration  Plan.  CAPS  II  is  slated  to  remain  in  service  for  a  while.  It  will  even  be 
enhanced  in  the  near  future  as  it  remains  a  primary  input  form  for  the  CONUS  Freight 
Management  System.  In  this  light,  CAPS  11  still  has  a  bright  future,  and  its  functions  may 
be  out  of  scope  for  C2IPS.  Nevertheless,  CAPS  11  could  be  assimilated  and  integrated 
into  C2IPS  with  a  net  streamlining  effect  for  the  aerial  port.  At  the  very  least,  CAPS  II 
should  have  more  of  an  interface  with  C2IPS  if  integration  proves  impractical. 

On  the  other  hand,  APACCS  has  no  future  in  the  move  toward  GCCS  compliant 
systems.  Rather  than  an  upgrade  for  the  system,  outright  replacement  is  preferred 
because  APACCS  performs  very  similar  functions  to  what  C2IPS  is  supposed  to 
accomplish.  APACCS  merely  possesses  more  levels  of  detail  for  aerial  port  operations. 
C2IPS  terminals  and  APACCS  terminals  often  reside  side  by  side  and  data  must  be 
transferred  between  to  two.  Eliminating  APACCS  and  adding  its  functionality  into 
C2IPS  would  eliminate  duplication. 

In  addition  to  developing  more  robust  application  modules,  C2IPS  should  expand 
to  fill  more  functions.  By  leveraging  the  previously  mentioned  architectural  changes, 
C2IPS  could  reach  into  many  more  places  on  a  given  base.  Mr.  Appel  stated  that  a  large 
base  like  Travis  has  about  80  workstations,  but  he  feels  that  the  need  is  actually  for  about 
300  terminals.  Many  of  these  terminals  may  only  need  web-based  occasional  access. 
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while  others  would  probably  need  full  client  capabilities.  Most  of  the  offices  that  are 
currently  excluded  from  C2IPS  access  can  not  get  access  because  of  the  previously 
mentioned  workstation  costs.  Additionally,  since  the  program  could  not  afford  to  add 
workstations,  the  software  was  not  developed  to  support  these  functions.  Examples  of 
functions  for  inclusion  include  the  base  billeting  office,  public  affairs,  base  historians, 
security  police,  base  weather,  inflight  kitchen,  base  hospital,  fire  department,  airfield 
management,  unit  commanders,  and  a  myriad  of  other  support  agencies.  These  offices  all 
have  some  occasional  need  for  information  contained  in  the  database.  Answering  the 
requests  for  information  from  these  offices  can  generate  considerable  workloads  for 
command  post  and  operations  staffs. 

These  are  but  some  of  the  most  glaring  examples  of  capabilities  that  C2IPS  should 
have.  Space  does  not  allow  discussion  of  all  the  specifics.  Only  when  C2IPS  acquires 
more  of  these  roles  will  it  become  the  do-everything  system  that  users  expect  in  the 
information  age.  C2IPS  needs  to  assimilate  many  more  scheduling,  aerial  port,  and 
ancillary  functions  if  AMC  is  to  reap  the  benefits  of  automation  on  the  grand  scale. 
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VI.  CONCLUSION 


As  the  primary  AMC  wing  level  command  and  control  system,  C2IPS  is  an 
important  tool  in  accomplishing  AMC’s  worldwide  mission.  In  the  four  major  study 
areas,  several  opportunities  for  improvement  were  found.  In  many  cases,  AMC  is 
addressing  these  issues.  Throughout  the  AMMP,  many  references  exist  to  changing  to  a 
three-tier  client/server  architecture,  implementing  “thin  clients,”  and  improving  data 
communications.  Throughout  the  study  these  goals  were  examined,  and  many  are  on 
track  or  only  need  minor  adjustments. 

Improving  the  functionality  of  C2IPS  is  also  mentioned  indirectly  in  the  AMMP, 
but  the  goals  were  not  terribly  specific.  This  study  examined  several  possible  systems 
that  could  be  included  in  C2IPS  as  it  acts  as  the  overarching  wing  level  command  and 
control  information  system.  These  systems  all  appear  to  be  viable  functional 
improvements  for  C2IPS,  and  are  in  various  stages  of  study.  The  more  of  these 
stovepiped  systems  tliat  can  be  included  in  the  overall  system,  the  less  manpower  will  be 
required  to  maintain  and  use  these  functional  capabilities.  Most  importantly,  better  wing 
level  communications  will  result. 

AMC  needs  to  continue  on  its  course  toward  integrating  and  improving  its 
information  systems.  Users  must  be  able  to  “pull”  whatever  information  they  need  about 
air  mobility  from  a  fast,  reliable  and  easy-to-use  system.  The  mission  effectiveness  of  the 
conunand  will  improve  as  information  flows  smoothly  between  users.  The  ability  to 
effectively  manage  information  is  fast  becoming  an  acknowledged  and  required  military 
competency.  Solid  information  warfare  abilities  will  allow  the  United  States  to  fight 
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cheaper,  faster,  and  better.  As  a  global  command,  AMC  must  be  in  the  lead  with  the 
required  technologies  if  it  is  to  continue  to  succeed  in  performing  its  mission. 
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APPENDIX  A:  GLOSSARY 


ADANS—AMC  Deployment  Analysis  System.  Used  to  plan  missions  at  the  headquarters  level. 

AFB— Air  Force  Base. 

AFORMS-Air  Force  Management  System.  Information  system  used  to  maintain  aircrew  flying 
records 

AHS”Aircraft  History  System.  Used  at  AMC  to  generate  reports  on  mission  effectiveness  and 
aircraft  utilization. 

ALTRV-- Altitude  Reservation. 

AMC“Air  Mobility  Conunand.  US  Air  Force  operator  of  airlift  system  and  C2IPS 
owner/operator. 

AMMP-Air  Mobility  Master  Plan.  AMC’s  corporate  strategic  plan  that  maps  up  the  command’s 
goals. 

AMSS—Air  Mobility  Support  Squadron.  Units  located  at  forward  locations  that  service 
transiting  aircraft  on  AMC  missions. 

APACCS— Aerial  port  automated  command  and  control  system. 

C2IPS— Command  and  Control  Information  Processing  System. 

C4I~Command,  control,  communications,  computers  and  intelligence.  Overarching  abbreviation 
for  just  about  any  type  of  command  and  control  or  computer  system. 

CAASS— Computer  Aided  Aircrew  Scheduling  System.  Used  by  flying  squadrons  to  schedule 
aircrew  members. 

CAMS“Consolidated  Aircraft  Maintenance  System. 

CAPS“Consolidated  Aerial  Port  Subsystem.  Used  to  manage  aerial  ports,  mostly  handles  cargo 
manifesting  functions.  CAPS  II  is  the  current  version,  RCAPS  (Remote)  and  DCAPS 
(Deployed)  are  the  deployed  versions. 

COE-Common  Operating  Environment.  A  set  of  protocols  and  standards  to  apply  to  all 

command  and  control  systems  used  by  the  DoD.  Attempts  to  standardize  data  formats 
and  interfaces  between  systems  to  ensure  interoperability. 

CONUS—Continental  US. 

COTS-Commercial-Off-The-Shelf. 
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CSC-Computer  Sciences  Corporation.  C2IPS  prime  contractor. 

DCE-Distributed  Computing  Environment.  A  set  of  standards  for  replicating  data  across 
multiple  servers  to  maintain  redundant  capability  to  access  the  data. 

DDN— Defense  Digital  Network.  Defense  department  wide  area  network. 

DEC— Digital  Equipment  Corporation.  Manufacturer  of  current  C2IPS  workstation  hardware. 

DISA—Defense  Information  Systems  Agency.  Responsible  for  assuring  interoperability  between 
different  military  services’  information  system. 

DII— Defense  Information  Infrastructure. 

DISN-Defense  Information  Systems  Network.  New  term  for  DDN. 

DOD-Department  of  Defense. 

DOS— Disk  Operating  System.  A  simple,  commonly  available  computer  operating  system. 

DTS-Defense  Transportation  System.  Overall,  generic  term  for  all  DOD  transportation  services. 

EDS— Electronic  Data  Systems. 

ESP-2000-Enhanced  Scheduling  Program-  2000.  A  commercially  developed  wing-level 
scheduling  program  currently  under  AMC  test. 

GCCS— Global  Command  and  Control  System.  Not  only  a  system,  but  a  set  of  standards  (COE) 
that  supporting  systems  must  follow. 

GDSS— Global  Decision  Support  System.  AMC’s  command  and  control  global  corporate 
database. 

G081— AMC  aircraft  maintenance  information  system. 

GTI— Global  Technologies  International. 

GTN— Global  Transportation  Network.  A  US  Transportation  Command  owned  system  that  reads 
data  from  dozens  of  other  DoD  and  conunercial  systems  to  provide  a  single  place  to  track 
the  movement  of  cargo  and  personnel. 

GUI— Graphic  user  interface. 

HQ— Headquarters. 

HTTP— HyperText  Transfer  Protocol.  Protocol  used  to  transfer  information  on  the  WWW. 
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INMARSAT— International  Maritime  Satellite. 

IPS-Information  Processing  System,  sometimes  used  as  an  abbreviation  for  C2IPS. 

ITV-Intransit  Visibility.  The  ability  to  track  personnel  and  cargo  while  in  transit.  GTN  is 
designed  to  provide  this. 

JOPES-Joint  Operation  Planning  and  Execution  System.  A  system  used  to  plan  major 
operations  around  the  world.  It  is  both  a  computer  system  and  a  written  set  of 
procedures  for  planning. 

LAN-Local  Area  Network.  Connects  closely  located  computers  together. 

MAJCOM— Major  Command.  AMC  is  a  MAJCOM. 

MAN— Metropohtan  Area  Network.  Connects  computers  and  LANs  together  in  a  city  or  base 
sized  environment. 

MASMS-Military  Airspace  Management  System.  A  system  used  to  reserve  airspace  for  military 
operations. 

MLS— Multi-Level  Security. 

NATO— North  Atlantic  Treaty  Organization. 

OS-Operating  System. 

PC— Personal  Computer. 

RAM— Random  access  memory. 

RDBMS— Relational  Database  Management  System. 

SQL-Structured  Query  Language. 

TACC-Tanker/Airlift  Control  Center.  Exercises  global  control  AMC  flights  for  HQ  AMC. 

TAFIM-Technical  Architecture  Framework  for  Information  Management. 

TALCE— Tanker/ Airlift  Control  Element.  Command  and  control  forces  that  manage  aircraft  at 
deployed  locations. 

TBMCS— Theater  Battle  Management  Core  Systems. 

TDC-Theater  Deployable  Communications.  Large  deployable  communications  package. 

UNIX-Operating  system  that  supports  open  system  architecture 
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WAN-Wide  Area  Network.  Connects  computers,  MANs  and  LANs  together  over  great 
distances. 

WINDOWS-A  commonly  used  computer  operating  environment  made  by  Microsoft  Corp. 
WWMCCS-Worldwide  Military  Command  and  Control  System.  GCCS  replaced  WWMCCS. 
WWW-World  Wide  Web. 
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C2IPS:  A  MODEL  FOR  THE  FUTURE 


Major  Frederick  M.  Koennecke,  Jr  (AFTT/GMO/LAS/QTY-?) 

Advisor:  Alan  R.  Heminger,  PhD.  (LAS) 

As  Air  Mobility  Command’s  (AMC’s)  primary  wing-level  command  and  control 
system,  the  Command  and  Control  Information  Processing  System  (C2IPS)  plays  a 
critical  role  in  the  success  of  AMC  operations  around  the  world.  C2IPS  needs 
improvement  if  it  is  to  fulfill  enough  of  its  user’s  needs  to  truly  improve  AMC’s 
operational  capability.  This  paper  examines  some  of  these  improvements  from  a 
cost/benefit  perspective  in  the  context  of  improving  AMC’s  mission  capability. 

The  paper  examines  four  major  areas  for  improvement  and  makes 
recommendations  in  each  area.  The  first  concerns  moving  C2IPS  to  a  three-tier 
client/server  architecture  to  improve  response  time  and  reliability.  The  second  area  adds 
to  the  three-tier  concept  by  using  a  “thin  client’’  approach  to  reduce  workstation  hardware 
and  software  requirements.  Third,  the  supporting  communications  infrastructure  for  both 
fixed  node  and  deployed  node  operations  needs  to  better  support  user  needs  while 
maintaining  minimal  costs.  Finally,  several  similar  and  overlapping  systems  could  be 
migrated  in  the  overall  C2IPS  structure  to  minimize  duplication  and  expense. 

All  four  of  these  areas  offer  opportunities  for  both  performance  and  cost 
improvements  over  the  existing  system,  and  thus  can  improve  AMC’s  overall  mission 
effectiveness. 


